Participantes y roles funcionales
La identificación de roles se infiere de lo que cada persona dijo y de cómo el resto se dirigió a ella. Donde el transcript no permite atribución confiable, se marca como no confirmado.
| Persona | Organización | Rol funcional en el proyecto | Peso en la decisión |
|---|---|---|---|
| Diego | NetPay | Sponsor de negocio. Da el contexto del modelo de datos, define la visión del journey en WhatsApp, marca la dirección arquitectónica (sacar la lógica de Salesforce) y prioriza los dolores. | Decisor |
| Ash / Ashley | NetPay | Conduce la sesión, recopila entregables, presiona la fecha y define el alcance de la POC. Es quien traslada el resultado al comité y al equipo de abasto. | Operador del proceso de decisión |
| René | NetPay | Dueño del proceso de originación. Hizo la demo end-to-end de Salesforce, Nufi y contrato. Fuente primaria de la documentación operativa. | Fuente de verdad operativa |
| Carlos Córdoba | NetPay | Pricing / rentabilidad. Aprueba manualmente las excepciones fuera de parámetro. Su criterio es lo que se pretende modelar como "Carlos sintético". | Fuente de verdad del modelo |
| Misha | NetPay | Revenue Management. Propuso la arquitectura de agentes desacoplados. Ya tiene una iniciativa propia de agentización del proceso de cotización. | Arquitecto de opinión |
| Comercial senior no confirmado | NetPay | Se integró tarde. Aportó la evidencia más concreta del dolor: el conteo de ~35 campos, el gaming del cotizador y la degradación de rentabilidad posterior. | Voz del usuario |
| Manu no confirmado | NetPay | Planteó la pregunta de autogestión: qué pasa cuando cambian políticas, productos, tasas mínimas o giros. | Continuidad operativa |
| Jules Avila | DashOne | Descubrimiento técnico y de proceso. Llevó una lista numerada de preguntas al chat de la llamada. | — |
| Daria Nikitina | DashOne | Descubrimiento de negocio y datos. Detectó el problema de calidad del histórico y fijó el compromiso de autogestión y capacitación. | — |
Sergio Miranda — equipo de Altas. Hoy hace manualmente el seguimiento y los recordatorios a los socios, que es el segundo dolor más citado. Nelson — equipo de René, configuró el esquema de permisos en Salesforce. Gabriel Ojeda — Operaciones, valida documentos en Nufi. Dani — valida la evidencia de contacto en la etapa de apartado. Equipo de Riesgo — consulta PLD/listas negras en paralelo, no en todos los casos. Equipo de abasto — compras, destinatario final de la decisión.
Resumen ejecutivo
- El dolor prioritario no es la rentabilidad, es la velocidad. Diego lo dijo textualmente: el problema mayor hoy no es el margen, es cómo ejecutar más rápido. El modelo financiero está probado y les da tranquilidad; lo que no funciona es la experiencia.
- El cuello de botella concreto son ~35 campos y un prospecto obligatorio. No se puede cotizar sin antes crear prospecto, apartado, company, branch y store. El socio quiere cinco preguntas y un rango con el que salir a negociar.
- Existe un problema de integridad del dato con impacto en revenue. Los socios que conocen el cotizador manipulan las variables para forzar la tasa que quieren. Esto se descubre reactivamente, cuando el comercio ya opera y el margen no da.
- El cliente propuso la arquitectura. Misha pidió explícitamente no embeber el cotizador en WhatsApp: un agente conversacional que consulta a un servicio de cotización desacoplado — el "Carlos sintético".
- La POC tiene un alcance deliberadamente estrecho y ya confirmado por escrito. Funcional, sin conexión a Nufi ni Salesforce. Real en el cálculo y en la interacción, y solo en eso. El simulador en Excel y los flujos de Nufi ya están entregados; falta el histórico.
- La fecha es política, no técnica. Fin de agosto existe porque NetPay necesita el insumo para un comité interno antes de que el proceso escale a abasto.
- Hay una oportunidad arquitectónica mayor abierta. Diego declaró que le urge sacar la lógica del cotizador de Salesforce y que van a construir una capa de abstracción. Eso es un proyecto de otro tamaño y aún no tiene dueño.
- Lo que se conversa como "un bot de WhatsApp" es en realidad el rediseño del proceso de originación completo. Ver Apéndice B — es la aclaración más importante del documento.
Modelo de negocio y de datos
Diego intervino específicamente para nivelar el vocabulario, lo cual señala que el modelo jerárquico es condición previa para diseñar cualquier flujo conversacional.
| Nivel | Qué es | Cardinalidad | Impacto en cotización |
|---|---|---|---|
| Cliente | Raíz del árbol. La entidad comercial. | 1 | Se puede cotizar el cliente completo, incluyendo múltiples RFCs. |
| Company | Un RFC. Datos fiscales del negocio y su actividad. | 1 a N por cliente | Nivel más frecuente de cotización. Requiere simulador completo. |
| Branch | Sucursal física. Lleva comprobante de domicilio y horarios de atención. | 1 a N por company | No requiere simulador: cuelga de una cotización existente. |
| Store | Equipo, no ubicación. Diez terminales en una sucursal son diez stores. Un checkout de e-commerce también es un store. | 1 a N por branch | No requiere simulador. |
Nota de discrepancia: Diego ejemplificó "un checkout, un link y 10 terminales" y concluyó que ese cliente tendría "dos stores", lo cual no cuadra con la regla de un store por equipo. Puede ser un lapsus o puede existir una agrupación por tipo de producto. Confirmar la regla exacta de conteo de stores antes de modelar el cálculo por número de terminales.
La secuencia de creación es obligatoria y frágil: company → branch → store, y dentro del simulador la captura por pestañas debe hacerse en orden o "el simulador no responde correctamente".
Proceso actual, extremo a extremo
Fase A · Prospección y apartado
Fase B · Simulador de tasas
Se accede entrando al company y presionando "Simulador" (variante tarjeta presente). Cuatro pestañas más un panel de rentabilidad reservado a pricing.
| Pestaña | Campos | Observación levantada en sesión |
|---|---|---|
| General | Company asociado, giro (natural / agregador), familia (normalmente "adquiriente"), ticket promedio, volumen operado por lectores, facturación del company, concentradores, terminales y su tecnología (LAN, 3G). | "Volumen operado por lectores" siempre es 0%. Otro campo "siempre es 30%". Ambos son candidatos a eliminar o precargar. |
| Volumen | Distribución porcentual por tipo de tarjeta (débito, crédito, crédito internacional, Amex). La suma debe dar 100%. | La herramienta propone una distribución sugerida; el socio puede sobrescribirla libremente. Este es uno de los puntos donde ocurre el gaming. |
| Configuraciones | Chip sugerido, operador celular (Telcel, AT&T), y checkboxes de condiciones: acelerador, pago especial, rollo gratis, topado, integración, terminal especial, fondo de reserva. | El fondo de reserva es una medida preventiva de uso poco frecuente. |
| Tasas | Renta de equipos, tasa de débito, tasa de crédito. La herramienta muestra un mínimo obligatorio y un sugerido. | Para pedir algo por debajo del mínimo hay que marcar "solicitud de aprobación" indicando qué tasa se quiere mover. |
| Escenario simulado | Rentabilidad calculada y desglose de costos. | Es lo primero que revisa Carlos Córdoba. Margen por encima de 10% ≈ aprobable. |
Bifurcación de salida
El sistema emite automáticamente una carta de condiciones: fecha, destinatario (el comercio), condiciones ofrecidas, cantidad de equipos incluidos y facturación pactada. El socio puede mostrarla al comercio como propuesta preautorizada.
Estatus "en proceso". La carta nunca se muestra hasta que Carlos resuelva. Carlos dispone de una pestaña de gerente con parámetros que comercial no puede tocar, y antes de rechazar intenta reconfigurar para sostener rentabilidad positiva.
Las excepciones se manejan supremamente rápido y la respuesta en la mayoría de los casos es bastante favorable, tanto para la compañía como para el usuario del cotizador. Las excepciones hoy no son tanto nuestro dolor.
— Comercial senior, NetPay
Fase C · Expediente y validación (Nufi)
Solo se pueden originar giros con participación igual o mayor al 10% en la constancia de situación fiscal. Por debajo de ese umbral el caso no procede.
No hay validación de identificación facial en la etapa de expediente. La biometría aparece únicamente al momento de la firma, como una de dos opciones (claves o biometría) en Mifiel.
Fase D · Alta, contrato y cierre
Sistemas, roles y arquitectura
| Sistema | Rol | Estado y dirección declarada |
|---|---|---|
| Salesforce | CRM, Partner Community para socios, y el cotizador construido custom dentro de la plataforma. Orquesta qué flow pedirle a Nufi. | A desacoplar Diego: le urge sacar la lógica de ahí. Van a construir una capa de abstracción para no depender de Salesforce en onboarding. |
| Nufi | KYB. ~30 flows configurables, OCR, validaciones cruzadas, consulta a lista nominal, PLD. Aduana del proceso: sin su "sí", nada avanza. | Subutilizado Tiene capacidades de IA que no están maduras y no se usan. NetPay quiere sustituir la revisión manual con IA. Durante la propia demo tuvo una migración de seguridad no anunciada que impidió el acceso. |
| Mifiel | Firma digital, conectado a Nufi. Claves o biometría. | Estable |
| Core | Herramienta in-house. Única fuente formal y de auditoría. Ahí vive el alta, la facturación de socios, la conciliación y la dispersión de pagos a comercios, y las condiciones finales realmente operadas. | Fuente del histórico real René fue explícito: los datos para extrapolar y predecir están en Core, no en Salesforce. |
| S3 | Repositorio de archivos. | Destino objetivo Hoy los documentos están repartidos entre Salesforce y Nufi. Hay una iniciativa con Operaciones para consolidar todo en S3. |
| Excel | Modelo original del cotizador. El modelo de Salesforce es una réplica. | Sombra activa Sigue en uso para escenarios que el modelo no cubre: grandes superficies, fórmulas especiales, tablas de rangos de tasas. También por hábito y para simular rápido frente al cliente. |
Puede que esté dado de alta en Core pero no en Salesforce. Entonces para mí es un cliente nuevo, pero ya eres un cliente existente. Alinear las tres herramientas también puede ser un problema.
— René, NetPay
Una vez completado el proceso, solo el socio puede modificar datos, y en la práctica el flujo se cancela y se reinicia desde cero. Hay dos razones acumuladas: legal — no es correcto manipular información que un área autorizada ya revisó; y técnica — los flows tienen los campos mapeados para la captura automática hacia Core, y cambiarlos rompe la automatización. René reconoció que si se pudiera clonar la automatización y editar datos puntuales sin reiniciar, "sería una de las oportunidades".
Usuarios, jerarquía y permisos
| Rol | Función | Licencia / acceso | Visibilidad |
|---|---|---|---|
| Socio comercial | Nivel más bajo. Es quien vende y quien debería ejecutar la cotización. | Partner Community | Solo sus propias oportunidades |
| Master | Manager de varios socios | Sales Cloud | Las suyas y las de sus socios |
| Líder comercial | Antes "regional" | Sales Cloud | Su rama completa hacia abajo |
| Director | Tope de la estructura | Sales Cloud | Todo |
Diego lo señaló sin que nadie preguntara: es bien importante que los socios no puedan ver las oportunidades de otros socios, "porque ahí luego puede caer en malas prácticas". Los permisos actuales fueron configurados por Nelson en Salesforce y siguen el árbol jerárquico.
Implicación no tratada en la sesión: en WhatsApp la identidad es el número de teléfono, no una sesión autenticada. Trasladar este modelo de permisos requiere resolver el mapeo teléfono ↔ usuario de Partner Community, y decidir el comportamiento ante números no registrados, compartidos, reasignados o dados de baja. Es un requisito de seguridad duro sin diseño asociado.
Otros equipos que intervienen
- Evidencia y apartado — equipo de Dani.
- Pricing / excepciones — Carlos Córdoba, dentro del equipo de Misha.
- Revenue Management — Misha. Detecta comercios cuyo margen no da y dispara el proceso de recotización.
- Operaciones — validación documental en Nufi.
- Riesgo — PLD y listas negras, en paralelo y no sobre todos los casos.
- Altas — Sergio Miranda. Giro natural ante Prosa, generación de contrato, alta en Core, y hoy también el seguimiento manual a los socios.
- Abasto — compras. Destinatario de la decisión una vez validada la POC.
Volumetría y distribución
| Tipo de originación | Participación | ¿Requiere simulador? | Nota |
|---|---|---|---|
| Tipo client | 60% | Sí | Simulador completo |
| Tipo company | 5% | Sí | Simulador completo |
| Multi-RFC | 1% | Sí | Simulador completo |
| Tipo branch y store tradicional | ~34% | No | Cuelga de una cotización existente |
Aproximadamente dos terceras partes de la originación pasan por el simulador. Esa es la superficie real de dolor y la base de dimensionamiento del beneficio.
Daria ancló la conversación al volumen previamente estimado de 300–400 contactos nuevos al mes y René confirmó que ese flujo completo aplica únicamente a los tipos client y company.
Recotización de branch o store tradicional
Si un socio necesita recotizar sobre una cuenta existente, el camino actual es: hacer el boarding con las condiciones vigentes, luego entrar por servicio post-venta y cambiar manualmente las condiciones. Si el resultado cumple criterio, la herramienta aprueba automático; si no, escala al equipo de Carlos Córdoba para revisión manual por rentabilidad.
No se cuantificó en la sesión ninguno de los siguientes: tiempo promedio de captura de una cotización, porcentaje de casos con retrabajo o rechazo documental, porcentaje de cotizaciones con datos manipulados, costo del ajuste al alza posterior, volumen de tickets de soporte, ni número de socios activos que usan el simulador. Sin esa línea base no habrá forma de demostrar el valor de la solución después de implementarla.
Dolores y fricciones
Ordenados por prioridad declarada, no por severidad técnica. Diego fue explícito sobre cuáles son "los dolores de esta primera etapa".
| ID | Dolor | Evidencia en sesión | Prioridad |
|---|---|---|---|
| D-01 | Exceso de campos para obtener una respuesta. ~35 campos contados en el Excel. La queja no es el proceso ni la herramienta, que "funciona bastante bien", sino la cantidad de información a diligenciar antes de recibir un número. | "Pregúntame las cinco cosas esenciales para que me des más o menos una oferta con la que yo pueda salir a negociar." | Crítica |
| D-02 | No se puede cotizar sin prospecto. Hay que crear prospecto, esperar validación de evidencia, apartar, y crear company, branch y store antes de acceder al simulador. El socio en la calle no tiene ni el RFC del comercio. | Ash pidió una "precotización" que no exija generar prospecto. René: "¿cómo hago ese simulador portátil?" | Crítica |
| D-03 | Manipulación de variables para forzar la tasa. El socio que ya conoce el cotizador juega con los números hasta obtener la tasa que quiere ofrecer. El que no tiene el dato simplemente lo inventa o lo estima. | "Estamos casi que alterando el resultado." Consecuencia: valores lejanos de la realidad y ninguna certeza del valor real de la oportunidad. | Crítica |
| D-04 | Herramienta de escritorio para un usuario de calle. El socio comercial no trabaja en escritorio y por eso rechaza la herramienta. | Diego lo puso como el primer dolor obvio de la lista. | Crítica |
| D-05 | Seguimiento inexistente del lado del socio. Trae muchas oportunidades en paralelo, es "más tiburón que administrador" y no da seguimiento. Hoy Sergio Miranda y su equipo persiguen manualmente. Los socios preguntan repetidamente dónde va su caso y qué sigue. | Diego lo nombró como el segundo dolor de la lista. | Alta |
| D-06 | Captura repetida. Se piden los mismos datos varias veces y además se solicitan los documentos que ya contienen esos datos. | "¿Para qué me lo vuelves a pedir si vas a agarrar el documento?" | Alta |
| D-07 | El Excel sombra sobrevive. Formalmente no debería usarse. Persiste por hábito, para simular rápido frente al cliente sin entrar a la herramienta, y porque hay escenarios que el modelo no soporta. | "Es muy común que el socio se quiera hacer el loco, irse por el Excel y tratar de irse por la avenida con Carlos Córdoba para no pasar este proceso doloroso." | Alta |
| D-08 | Degradación de rentabilidad posterior. Cuando el comercio opera y no cumple lo declarado, el margen no cubre el costo. Hay que ajustar al alza y se corre el riesgo de perder al comercio. Los controles son reactivos, no proactivos. | Diego lo matizó: Misha lo tiene mitigado con un proceso alterno de recotización. "Nuestro mayor problema ahorita no es ese." | Media declarada · alta latente |
| D-09 | Secuencia de captura frágil. Si no se llena en el orden correcto, el simulador no responde correctamente. | René lo advirtió durante la demo. | Media |
| D-10 | Modificar un dato exige reiniciar el flujo completo. Por restricción legal y por el mapeo de campos que alimenta la automatización hacia Core. | "Vuelves a abrir la misma agonía." | Media |
| D-11 | Validación documental manual. Operaciones revisa a mano lo que Nufi ya prevalidó. Nufi tiene IA pero inmadura y no se usa. | René: "somos conscientes de que se podría aplicar inteligencia artificial en lugar de que una persona ande checando." | Media · fuera de POC |
| D-12 | Desalineación entre herramientas. Un comercio puede estar en Core y no en Salesforce, apareciendo como nuevo cuando ya es existente. | René lo levantó espontáneamente. | Media · fuera de POC |
| D-13 | Automatización por pedazos. Contrato, captura y validaciones se automatizaron internamente, pero cara al cliente el onboarding no cambió de fondo. Un heavy user lo hace con los ojos cerrados; alguien nuevo "claramente le va a batallar". | Diego, respondiendo directo a la pregunta sobre cuánto ha cambiado el proceso. | Contexto |
Dos aclaraciones importantes para no diseñar sobre un supuesto falso. Primero: las excepciones que aprueba Carlos no son un dolor — se resuelven rápido y con respuesta mayoritariamente favorable. Segundo: el modelo financiero es un activo. "Está financieramente probado, nos da un respaldo y una tranquilidad en términos financieros." Lo que no es amigable es la experiencia. Cualquier propuesta que sugiera reemplazar el modelo, en lugar de envolverlo, va a encontrar resistencia.
Solución esperada
El journey que describió Diego
La arquitectura que propuso Misha
No embeber el cotizador dentro de WhatsApp. El agente conversacional consulta a un servicio separado — el agente cotizador, o "Carlos sintético". El agente de WhatsApp le manda el contexto, el cotizador devuelve preguntas de aclaración, esas preguntas se responden por WhatsApp, y el ciclo se cierra con una recomendación.
La lógica de la recomendación que Misha describió es de vecino más cercano sobre el histórico: si un comercio tiene características similares a otro ya cotizado, se ofrece algo parecido — con el objetivo explícito de que las condiciones de mercado no se disparen y de que dos comercios comparables no terminen en posiciones desiguales.
Señal El cliente ya trae una tesis de arquitectura y está trabajando internamente en agentizar el proceso. DashOne debe validarla y construirla, no proponer una alternativa que la contradiga sin argumento fuerte.
Simplificación por inferencia
Diego identificó el mecanismo concreto de ahorro: hay campos que en 98–99% de los casos toman el mismo valor y aun así se piden cada vez. La propuesta es un wizard o template con valores recomendados y edición opcional. Jules amplió el principio: inferir del histórico, prellenar cálculos y pedir confirmación en vez de captura, extraer datos de los documentos y de casos previos, y complementar con benchmark de mercado.
Autogestión
La pregunta más importante que hizo NetPay sobre el modelo de operación: qué pasa cuando cambia una política, entra un producto nuevo, se modifican tasas mínimas o se agrega un giro. ¿Hay que contactar a DashOne?
Alcance de la prueba de concepto
Jules forzó la definición al preguntar qué significaba "prueba de concepto" para ellos, distinguiendo entre un experimento desechable y algo conectado a datos productivos. La respuesta acotó el alcance con precisión, y NetPay la formalizó por escrito al cierre del día.
- La prueba de concepto tendrá alcance funcional, sin conexión con herramientas como Nufi o Salesforce.
- Estará acotada al conjunto de variables detallado más abajo.
- El objetivo es tenerla lista antes de que finalice agosto.
- Documento de flujos de Nufi — entregado
- Simulador en Excel — entregado
- Base de datos con histórico mínimo de 3 meses de cotizaciones — pendiente
Este mensaje resuelve la ambigüedad de alcance detectada en sesión. "Funcional sin conexión" es una definición operable: el motor calcula de verdad, no hay integraciones. Queda registrado como la definición vigente.
- Interacción completa en WhatsApp.
- Flujo navegable que muestre cómo se vería y cómo se interactuaría — "tipo menú de flujos".
- El cálculo debe ser real y correcto. Ash: "que sea funcional nada más al momento de poder generar estas cotizaciones."
- Cotización con un conjunto reducido de variables, sin prospecto previo.
- Capacidad de identificar fricciones y realinear antes de una salida formal.
- No es un MVP. Ash lo descartó explícitamente por complejidad.
- Sin integración a Salesforce, Nufi, Mifiel o Core. "No conectar la información con alguna herramienta por detrás."
- Sin datos productivos.
- Sin carga de documentos ni expediente.
- Sin landing ni app de seguimiento — Jules las mencionó como evolución posterior y Ash coincidió en dejarlas para etapas siguientes.
Durante la llamada Daria resumió el alcance como "un UX/UI de look and feel, sin que esté funcional" y Ash asintió — pero inmediatamente añadió que sí debía ser funcional al generar cotizaciones y que lo importante era asegurar cómo es el cálculo. Eran dos expectativas distintas conviviendo en la misma frase, y es el tipo de acuerdo que se rompe el día de la demo.
El recap escrito de NetPay lo resolvió el mismo día: alcance funcional, sin conexión a herramientas. Lectura operativa vigente: journey navegable, motor de cálculo real en el corazón, cero integraciones.
Variables acordadas para el cotizador de la POC
Lista formal confirmada por NetPay. Difiere y amplía la versión verbal de la sesión en dos puntos importantes: el tipo de terminal —no solo la cantidad— y la incorporación de los tramos de meses sin intereses a la distribución de volumen.
| Variable | Valores / dominio | Nota de diseño |
|---|---|---|
| Facturación mensual | Monto | Volumen de venta del company. Junto con el ticket promedio determina el número de transacciones. |
| Ticket promedio | Monto | — |
| Tipo de terminales | A910S · IM30 · Aries 8 · M1 · UROVO · P8 Dual | Nuevo En sesión solo se habló de "cantidad de terminales". La lista formal exige modelo, lo que implica una tabla de costo y renta por modelo que debe estar en el simulador. |
| Distribución de volumen |
% Débito (venta directa) % Crédito (venta directa) % Internacional % AmEx (venta directa) % MSI PROSA / eGlobal % MSI AmEx |
Ampliado Seis tramos, no cuatro. Los dos de meses sin intereses no se mencionaron en la llamada y tienen estructura de costo distinta. Es además el punto exacto donde ocurre la manipulación de variables descrita en D-03. |
| Familia | Categorías de negocio | Se requiere el catálogo cerrado de categorías. |
| Giro | Giro Natural · Giro Agregador | Determina parámetros mínimos y, aguas abajo, si aplica el trámite ante Prosa. |
Nominalmente son seis variables, pero al desglosarse la distribución en seis porcentajes y las terminales en seis modelos con su cantidad, el número efectivo de campos capturables ronda los quince. Sigue siendo una reducción sustancial frente a los ~35 del Excel, pero no es todavía el "pregúntame cinco cosas esenciales" que pidió el equipo comercial.
Ahí es exactamente donde entra RF-P06: la distribución de volumen y el mix de terminales son los mejores candidatos a inferencia por giro y familia, presentados como sugerencia editable en vez de captura. Bien resuelto, el socio contesta cuatro preguntas y confirma un bloque; mal resuelto, la POC reproduce el dolor que viene a eliminar.
Calendario y contexto de la fecha
Requerimientos funcionales
Prueba de concepto
| ID | Requerimiento | Origen |
|---|---|---|
| RF-P01 | Toda la interacción ocurre dentro de WhatsApp. | Ash, confirmado por Jules |
| RF-P02 | Permitir cotizar sin crear prospecto previo, sin apartado y sin estructura company/branch/store. | Ash, René, comercial senior |
| RF-P03 | Captura conversacional acotada a las seis variables acordadas, con el objetivo declarado de "cinco preguntas esenciales". | Comercial senior · lista Ash/René/Carlos |
| RF-P04 | Cálculo real de condiciones replicando fielmente el modelo del Excel y del simulador: renta de equipos, tasa de débito, tasa de crédito, con mínimos por giro. | Ash: "asegurar cómo es el cálculo" |
| RF-P05 | Devolver una propuesta con rango (mínimo obligatorio y sugerido) y clasificar el resultado en dentro de parámetros o requiere aprobación. | Proceso as-is · comercial senior |
| RF-P06 | Prellenado e inferencia de los campos que en 98–99% de los casos toman el mismo valor, editables por el usuario. | Diego |
| RF-P07 | Sugerir distribución de tarjetas por defecto según giro, permitiendo ajuste. | Proceso as-is · Carlos |
| RF-P08 | Producir una salida legible tipo carta de condiciones preliminar, marcada como no vinculante. | Proceso as-is |
| RF-P09 | Mostrar el journey completo en modo navegable (menú de flujos), aunque las etapas posteriores a la cotización estén simuladas. | Daria + Ash |
| RF-P10 | Sin ninguna integración a sistemas productivos. | Ash, restricción explícita |
Solución completa · fases posteriores
| ID | Requerimiento | Origen |
|---|---|---|
| RF-01 | Alta de prospecto desde WhatsApp, incluyendo la evidencia de contacto que hoy valida el equipo de Dani. | Diego |
| RF-02 | Selección del nivel de cotización: cliente, RFC único, multi-RFC, branch o store. | Diego |
| RF-03 | Recomendación de condiciones basada en histórico, con banda piso/techo y justificación por comparables. | Diego + Misha |
| RF-04 | Escalamiento a pricing con ticket trazable, y notificación de resolución al socio dentro del canal. | Proceso as-is + Diego |
| RF-05 | Servicio de cotización desacoplado ("Carlos sintético") consultado por el agente conversacional, con capacidad de repreguntar. | Misha, arquitectura solicitada |
| RF-06 | Solicitud y carga de documentos por WhatsApp, con depósito a Nufi vía API sin exponer la URL al socio. | Diego |
| RF-07 | Extracción de datos desde los documentos cargados para eliminar la recaptura. | Diego (D-06) + Jules |
| RF-08 | Seguimiento proactivo del caso: estatus, siguiente paso y recordatorios automáticos, sustituyendo el trabajo manual del equipo de Altas. | Diego (D-05) |
| RF-09 | Consulta de estatus a demanda por parte del socio. | Diego |
| RF-10 | Motor de reglas autogestionable: alta de productos, giros, tasas mínimas y flujos sin intervención del proveedor. | Manu + Ash |
| RF-11 | Conversión de precotización informal a cotización formal sin recapturar lo ya proporcionado. | Ash |
| RF-12 | Modificación de datos puntuales post-alta sin reiniciar el flujo, clonando la automatización. | René, declarado como oportunidad |
| RF-13 | Interfaz web complementaria para lista de contactos, cartera y seguimiento — fuera de WhatsApp por usabilidad. | Jules, avalado por Ash |
| RF-14 | Registro y trazabilidad de toda cotización generada, incluidas las precotizaciones informales que hoy ocurren en Excel sin dejar rastro. | Derivado de D-07 y D-03 |
| RF-15 | Controles preventivos sobre la veracidad de las variables declaradas, para atacar el gaming en origen. | Jules, planteado y no resuelto |
Requerimientos no funcionales
| ID | Requerimiento | Criticidad | Sustento |
|---|---|---|---|
| RNF-01 | Aislamiento de visibilidad por jerarquía. Un socio no puede ver oportunidades de otro socio. Master, líder y director ven su rama hacia abajo. | Bloqueante | Diego lo marcó como "bien importante" y lo ligó a la prevención de malas prácticas |
| RNF-02 | Identidad en el canal. Mapeo confiable entre número de WhatsApp y usuario de Partner Community, con política definida para números no registrados, compartidos o dados de baja. | Bloqueante | Derivado de RNF-01. No se discutió en la sesión. |
| RNF-03 | Autogestión total. NetPay debe poder dar de alta productos, giros, tasas mínimas y flujos sin depender de DashOne. Ash pidió expresamente la versión robusta, no el conector a Excel. | Alta | Manu, respaldado por Ash |
| RNF-04 | Capacitación y transferencia de conocimiento al equipo interno como parte del entregable. | Alta | Compromiso de Daria en sesión |
| RNF-05 | Fidelidad financiera. El cálculo no puede degradar los parámetros de rentabilidad del modelo existente, que NetPay considera un activo probado. | Bloqueante | Comercial senior + Carlos |
| RNF-06 | Integridad de la cadena de auditoría. Todo lo formal debe terminar en Core. La solución no puede crear un camino que evada ese registro. | Alta | René: Core es la única fuente formal ante una autoridad |
| RNF-07 | No romper el mapeo de campos que alimenta la captura automática de Salesforce hacia Core. | Alta | René, explicando por qué no se pueden editar datos post-alta |
| RNF-08 | Cumplimiento legal: la información validada por un área autorizada no puede ser modificada por terceros; los cambios los origina el socio. | Alta | René, restricción legal declarada |
| RNF-09 | Almacenamiento de documentos con destino S3, alineado a la iniciativa interna de consolidación. | Media | Diego |
| RNF-10 | Desacoplamiento de Salesforce. La lógica de cotización debe poder vivir fuera del CRM, en la capa de abstracción que NetPay planea construir. | Alta · estratégica | Diego: "me urge sacarlo de ahí" |
| RNF-11 | Tolerancia a indisponibilidad de terceros. Nufi ejecutó una migración de seguridad sin aviso durante la propia demo. | Media | Incidente observado en sesión |
| RNF-12 | Usabilidad móvil como requisito primario, no como adaptación. El usuario está en la calle. | Alta | Diego (D-04) |
| RNF-13 | Escalabilidad del catálogo de flujos: alrededor de 30 combinaciones vigentes en Nufi, con alta continua de nuevas. | Media | René |
| RNF-14 | Trazabilidad de la recomendación: para cada condición sugerida debe poder explicarse en qué comparables o reglas se basó. | Alta | Derivado del requisito de aprobación de pricing y del riesgo de sesgo del histórico |
Insumos comprometidos
De NetPay hacia DashOne
| Insumo | Dueño | Compromiso declarado | Estado |
|---|---|---|---|
| Lista formal de variables del cotizador | Ash + René | Mismo día de la sesión | Entregado |
| Cotizador / simulador en Excel con fórmulas | Carlos / René | Adjunto al recap | Entregado |
| Flujos de Nufi — ~30 combinaciones, documentos por flujo y validaciones cruzadas | René | Adjunto al recap | Entregado |
| Histórico de cotizaciones — mínimo 3 meses | Ash | "Tenemos que revisar cómo extraerlo" | Pendiente |
| Manual de originación | NetPay | — | Entregado en sesión |
| Acceso a Salesforce Partner Community (o sandbox con licencia) | Ash | Aceptado al cierre, sin fecha | Comprometido |
Rutas de los archivos compartidos
Con dos de los tres insumos críticos ya entregados, el camino crítico se reduce al histórico y al acceso a Partner Community — y de esos dos, solo el histórico bloquea trabajo técnico. El motor de cálculo puede arrancar de inmediato contra el simulador en Excel.
Debate sobre el histórico
El cálculo es determinístico: son fórmulas. Basta con casos de referencia — entrada y resultado esperado — para validar que el motor está bien. El histórico tiene valor limitado para esta etapa.
Todo lo que se pueda extraer sirve: histórico, perfil del vendedor, nivel de expertise. Más variables permiten detectar patrones que no son obvios desde los criterios ya conocidos. Si es fácil extraerlo, que lo manden completo.
Para la POC, Jules tiene razón: el motor se valida con casos de prueba. Para la recomendación inteligente de fases posteriores, Daria tiene razón, y además el insumo correcto no es el que se ofreció. Ash ofreció histórico de cotizaciones; lo que se necesita para recomendar sin destruir margen es el par cotizado ↔ operado real, y eso solo vive en Core. René lo dijo textualmente y nadie hizo la conexión durante la llamada.
Preguntas planteadas y respuestas obtenidas
| Quién | Pregunta | Respuesta |
|---|---|---|
| Daria | ¿Qué tan común es cotizar sin el detalle completo de stores? ¿Qué tan relevante es la información completa si los vendedores no la llenan? | René: depende de la naturaleza. Client, company y multi-RFC (66%) requieren simulador completo. Branch y store tradicional (34%) no, porque cuelgan de una cotización existente. |
| Daria | Los 300–400 contactos nuevos al mes, ¿pasan por este flujo completo? | René: sí, desde prospecto hasta simulador, pero solo los tipos client y company. |
| Jules | ¿Qué tan doloroso es para el socio dominar todas estas reglas? ¿Se equivocan, generan tickets? | Comercial senior: súper doloroso. No por el proceso ni la herramienta, sino por ~35 campos a llenar antes de recibir una respuesta. |
| Jules | Cuando el socio inventa datos para obtener mejores tasas, ¿qué tan grave es en compliance? ¿Existe validación de lo declarado? | Comercial senior: no hay validación previa. Resuelve al inicio, pero cuando el comercio opera y no cumple las condiciones aparece un problema de rentabilidad que obliga a ajustar al alza, con riesgo de perder al comercio. |
| Daria | ¿Qué tan comunes son esos casos? | Sin cifra. Comercial senior: hay controles internos pero reactivos, se detecta con el comercio ya operando. Diego: existe un proceso de Revenue Management que "regresa y recotiza". Sin cuantificar |
| Jules | ¿Vale la pena rediseñar los controles antes en el proceso, o incluso que el dato lo dé el cliente final y no el asesor? | No respondida. Diego redirigió a los dolores prioritarios de la primera etapa. Abierta |
| Jules | Cuando Carlos dice que el modelo de Salesforce es "réplica", ¿significa que siguen usando Excel? | Carlos: sí, para casos concretos — fórmulas especiales, tablas de rangos de tasas, grandes superficies. Escenarios que no están cargados en el modelo. |
| Jules | ¿Las variaciones de flujo de Nufi las dicta Salesforce? | René: sí. Según lo capturado, Salesforce le indica a Nufi qué flow invocar, y eso determina qué documentos se piden. |
| Jules | Si hay que modificar información después del alta, ¿quién lo hace? | René: el socio, por restricción legal. Internamente no se toca. En la práctica se cancela el flujo y se empieza de cero. |
| Jules | ¿Eso está bien o mal? ¿Querrían algo controlado? | René: tiene que ser controlado por seguridad de la información, pero poder cambiar datos puntuales sin reiniciar "sería una de las oportunidades". |
| Jules | ¿Qué es exactamente "la automatización" que se rompe? | René: la captura automática de Salesforce hacia Core. Antes la hacía manualmente el equipo de asesores, campo por campo. |
| Daria | ¿En Core se respalda absolutamente todo? | René: sí. Además ahí vive el servicio post-venta, el control de facturación de socios y la conciliación para dispersión de pagos a comercios. |
| Daria | ¿Es Core el que devuelve la conciliación para los outliers de revenue? | René: sí. En Core viven las condiciones finales. "El histórico real para extrapolar y predecir está en Core." |
| Jules | ¿Qué tanto usan Nufi? ¿Solo valida documentos? | René: es también su problema. Saben que se podría aplicar IA en lugar de revisión humana y quieren hacerlo, pero hoy lo usan solo como verificador. |
| Jules | ¿Valida CURP, RFC, OCR, INE? | René: sí, todo eso, más PLD y listas negras — aunque esa parte la usa el equipo de Riesgo, no Operaciones, y no en todos los casos. |
| Jules | ¿Valida identificación facial? | René: no en esa etapa. La biometría aparece en la firma, como alternativa a las claves en Mifiel. |
| Jules | ¿El flujo es OCR, llenado de campos y revisión humana? | René: sí, más consultas a portales externos como la lista nominal del INE. Le ha pasado que suben una INE que ya no es válida. |
| Jules | ¿Quién valida en cada paso? | René: el equipo de Operaciones, bajo el perfil "analista" de Nufi. Ejemplo nombrado: Gabriel Ojeda. |
| Jules | ¿Dónde y cómo se hace la firma digital? | René: desde Nufi se sube el contrato generado y se indican los correos destino. Mifiel ejecuta la firma por claves o biometría. |
| Manu | ¿Qué pasa si mañana cambia una política, entra un producto nuevo, cambian las tasas mínimas o se agrega un giro? ¿Tenemos que contactarlos? | Jules: plataforma autogestionable, sin dependencia. Ash: lo quieren robusto, en mediano y largo plazo, con autonomía total. Daria: la fase de desarrollo lo dejará editable y con capacitación completa. |
| Ash | ¿La POC sería dentro de WhatsApp? | Jules: sí, es lo más práctico para el usuario. A futuro también una landing o app, porque revisar la cartera completa en una lista plana de WhatsApp no es usable. Ash coincidió: carga y cotización en WhatsApp, seguimiento en interfaz aparte. |
| Jules | ¿Qué significa "prueba de concepto" para ustedes? ¿Experimento o algo productivo? | Ash: ni una cosa ni la otra. No es MVP. Es entender cómo se vería y cómo se interactuaría por WhatsApp, con el cálculo funcionando y sin conexión a herramientas de fondo. |
| Ash | ¿Necesitan una base histórica de tres meses? | Jules: sí, más las variables mínimas y el Excel con fórmulas — aunque cuestionó la utilidad del histórico para esta etapa por ser un cálculo determinístico. Daria: también los flujos de Nufi, y todo el histórico que sea fácil de extraer. |
| Jules | ¿Nos pueden dar acceso a la Partner Community, o a un sandbox? | Ash lo tomó como entregable. |
| Ash | ¿Tienen fecha para revisar la POC? | Jules revirtió la pregunta: que NetPay fije la fecha ideal y DashOne corta el alcance contra ella. Ash: fin de agosto, tolerancia primera semana de septiembre. |
Preguntas abiertas
Jules llevó una lista numerada de preguntas al chat de la videollamada — mencionó "la pregunta que dice aquí en la 2" y "mi pregunta número 9". Esa lista no se recorrió completa en sesión. Recuperarla y cerrarla por escrito es la acción de descubrimiento con mejor relación esfuerzo/valor.
| ID | Pregunta abierta | Por qué importa | A quién |
|---|---|---|---|
| Q-01 | ¿Cuál es la magnitud del problema de datos manipulados? ¿Qué porcentaje de comercios requiere ajuste al alza y cuánto cuesta? | Es la única palanca de ROI duro identificada. Sin cifra, el proyecto se vende solo por eficiencia. | Misha / Revenue Management |
| Q-02 | ¿Se busca solo automatizar el proceso actual o también rediseñarlo — por ejemplo, que el dato lo aporte el comercio y no el asesor? | Jules la planteó y quedó sin respuesta. Define si el alcance es un canal nuevo o un cambio de proceso. | Diego |
| Q-03 | ¿Cómo se resuelve la identidad y los permisos en WhatsApp? | RNF-01 es bloqueante y no tiene diseño. Nadie lo tocó. | Diego / Nelson |
| Q-04 | ¿La regla de conteo de stores es un store por equipo, o hay agrupación por tipo de producto? | El número de terminales es una de las seis variables del cálculo. Diego dio un ejemplo inconsistente. | René |
| Q-05 | ¿Qué criterio aplica Carlos que no está en el Excel? ¿Qué mueve en la pestaña de gerente y bajo qué lógica? | El "Carlos sintético" no se puede construir solo leyendo fórmulas. Carlos describió un juicio que no está codificado. | Carlos Córdoba |
| Q-06 | ¿Se puede extraer de Core el par condición cotizada ↔ condición operada real? | Es el insumo correcto para recomendar sin destruir margen. Aún no está solicitado formalmente. | René / Misha |
| Q-07 | ¿Cuál es el roadmap interno de NetPay? "La capa" de abstracción, la consolidación en S3, la IA en Nufi, la agentización de Misha. | Riesgo de solapamiento o de construir contra una plataforma que va a cambiar debajo. | Diego |
| Q-08 | ¿Cuál es el baseline operativo actual — tiempo de captura, retrabajo, tickets, adopción del simulador? | Sin línea base no hay forma de medir el impacto de la solución. | Ash / René |
| Q-09 | ¿Sigue en pie la sesión adicional de 30 minutos con Carlos, Manu y René para cerrar variables? | Ash la propuso; Diego y Misha delegaron. Se cubrió parcialmente al final de la misma llamada. | Ash |
| Q-10 | ¿Qué escenarios especiales quedan fuera del modelo — grandes superficies, tablas de rangos — y entran o no al alcance? | Definen si el motor cubre el 100% de los casos o deja un residual en Excel. | Carlos |
| Q-11 | ¿Cuál es el criterio de éxito de la POC y quién lo evalúa en el comité? | La POC es un insumo de decisión. Diseñarla sin conocer la rúbrica es diseñar a ciegas. | Ash |
Lo no dicho
Lectura de señales, subtexto e implicaciones que no se verbalizaron pero que condicionan la ejecución.
1 · La fecha no es de proyecto, es de comité
Ash lo dejó claro al cierre: dependen de otras áreas para decidir, el proceso se vuelve burocrático, quieren adelantar, y una vez que tengan la decisión la comunican a abasto. Traducción: la POC es el insumo para un comité interno con calendario propio. Perder fin de agosto probablemente no significa entregar en septiembre; significa esperar el siguiente ciclo de decisión. La fecha vale más que el alcance.
2 · La POC es un instrumento comercial
No está contratada, tiene ventana corta y su función real es desactivar el ancla de precio y ganar la decisión antes de que llegue a compras. Eso cambia las prioridades de construcción: debe verse producto, sentirse rápida y ser exacta en el cálculo. Un prototipo con cálculo aproximado destruye el argumento; un prototipo bonito sin cálculo lo debilita.
3 · Misha ya está construyendo algo
"Ya estamos empezando a entender cómo podríamos agentizar todo el proceso de cotización." Misha no solo opinó: propuso la arquitectura completa y la razonó. Es el aliado técnico más valioso de la sala y el riesgo de solapamiento más claro. Vale confirmar si Revenue Management tiene una iniciativa o un proveedor en paralelo, y posicionar a DashOne como quien construye la capa que Misha diseñó — no como quien propone algo distinto.
4 · Hay un proyecto más grande abierto y sin dueño
Diego declaró que le urge sacar la lógica del cotizador de Salesforce y que van a construir "la capa" para no depender del CRM en onboarding. Eso es un programa de arquitectura, no un bot de WhatsApp. Está mencionado y no tiene proveedor asignado. El bot es la puerta de entrada natural a esa conversación, pero regalarlo dentro del alcance del bot sería un error.
5 · El pitch debe medirse en tiempo, no en margen
Diego fue inusualmente directo: el mayor problema de hoy no es la rentabilidad, es cómo ser más rápidos y ejecutar mejor. Toda la narrativa de valor debe construirse sobre tiempo a cotización y casos completados sin retrabajo. El argumento de margen recuperado existe, es real y probablemente es más grande — pero es una venta de fase dos y necesita que alguien lo dimensione primero.
6 · El histórico ya está contaminado
Daria lo detectó de inmediato y Misha lo confirmó: la calidad del histórico depende del "colmillo" del socio, y hay casos movidos para forzar el resultado. La consecuencia lógica es incómoda y nadie la dijo en voz alta: entrenar recomendaciones sobre el histórico crudo es enseñarle al sistema a cotizar como los socios que manipulan las variables. Hay que segmentar por perfil de socio y contrastar contra desempeño real en Core antes de usarlo como referencia.
7 · Carlos es un riesgo de persona clave
Carlos minimizó su propio rol — "es totalmente igualito al Excel, no tiene mucha ciencia". Pero en la misma intervención describió una pestaña de gerente con parámetros que solo él puede mover y un criterio de reconfiguración que aplica antes de rechazar un caso. Eso no está en el Excel. Modelar el "Carlos sintético" leyendo fórmulas produce un cotizador, no a Carlos. Requiere entrevistarlo específicamente y con tiempo.
8 · Sergio Miranda no estuvo y es dueño del segundo dolor
El seguimiento y los recordatorios manuales que hoy hace su equipo son la segunda queja más citada por Diego, y RF-08 automatiza precisamente su trabajo. No participó en la sesión. Involucrarlo temprano evita que la automatización llegue como amenaza en lugar de como alivio.
9 · El indicador real de éxito es la muerte del Excel
Si después de implementar el socio sigue abriendo el Excel y buscando a Carlos por su WhatsApp personal, el proyecto no ganó. La métrica que importa no es número de cotizaciones generadas por el bot, sino porcentaje de cotizaciones originadas en el canal nuevo contra el total, incluyendo las informales que hoy no dejan rastro.
10 · DashOne ya está entregando diseño de solución sin contrato
En la sesión se entregó, gratis: la estrategia de inferencia y prellenado, el enfoque de extracción desde documentos, la disyuntiva conector-a-Excel contra motor propio, y el modelo de autogestión con transferencia de capacidad. Es descubrimiento legítimo y construye confianza, pero ese material puede terminar como especificación en un proceso de abasto. Conviene que lo próximo que se documente por escrito lleve autoría y encuadre.
11 · Nufi es una dependencia con fragilidad demostrada
Una migración de seguridad no anunciada dejó a René sin acceso durante su propia demo. Es un dato pequeño con implicación grande: el proceso completo se detiene si Nufi no responde, y NetPay no recibe aviso de sus cambios.
12 · La ambigüedad del alcance era la única grieta real de la POC
"Un look and feel sin que esté funcional" y "funcional al momento de generar cotizaciones" no son lo mismo, y las dos frases se dijeron con treinta segundos de diferencia y con acuerdo aparente. Era exactamente el tipo de acuerdo que se rompe en la demo. Cerrado El recap escrito de NetPay lo fijó el mismo día: alcance funcional, sin conexión.
13 · Los MSI aparecieron por escrito y no en la conversación
La distribución de volumen formalizada incluye MSI PROSA / eGlobal y MSI AmEx, dos tramos que nadie mencionó durante hora y media de demo. Los meses sin intereses tienen estructura de costo y de riesgo distinta a una venta directa, y son un componente habitual de la negociación comercial en adquirencia.
Dos lecturas posibles y conviene despejarlas antes de modelar: o el simulador ya los trata como tramos con costo propio y simplemente no salieron en la demo, o son un añadido reciente que Carlos maneja aparte. Si la POC calcula MSI con la misma lógica que la venta directa, el número va a estar mal en los casos donde más se negocia.
14 · "Venta directa" implica que existe algo que no lo es
Tres de los seis tramos vienen calificados como "venta directa": débito, crédito y AmEx. El calificativo sobra si no hubiera un contraparte. Puede referirse a la distinción natural/agregador, a un canal e-commerce, o a operaciones no presentes. Es una pregunta de treinta segundos que evita construir el mix de volumen sobre un supuesto equivocado.
15 · El tipo de terminal cambia la naturaleza del cálculo
En sesión René habló de "cantidad de terminales" como un driver de costo. La lista formal pide seis modelos específicos. Eso convierte una variable escalar en un mix, y presupone una tabla de renta y costo por modelo que debe existir dentro del simulador. Si esa tabla no está en el Excel entregado, es un insumo faltante que aún no está en la lista de pendientes.
Riesgos y supuestos
| ID | Riesgo | Impacto | Mitigación propuesta |
|---|---|---|---|
| R-01 | La fecha de fin de agosto está atada a un comité, no a un cronograma. Margen cero. | Crítico | Congelar alcance en una página firmada esta semana. Definir un corte mínimo entregable que se sostenga aunque falten insumos. |
| R-02 | Ambigüedad entre "no funcional" y "funcional en el cálculo". | Cerrado | Resuelto por el recap escrito de NetPay: alcance funcional, sin conexión a herramientas. |
| R-03 | Insumos críticos sin fecha ni dueño. | Reducido | Simulador en Excel y flujos de Nufi ya entregados. Queda pendiente el histórico de 3 meses y el acceso a Partner Community. |
| R-13 | La tabla de costo y renta por modelo de terminal puede no venir en el Excel entregado, siendo ahora una variable formal del cálculo. | Alto | Verificar contra el archivo recibido en las primeras horas de análisis y escalarlo de inmediato si falta. |
| R-14 | Tratamiento de los tramos MSI (PROSA/eGlobal y AmEx) desconocido: no se discutieron en sesión y tienen estructura de costo propia. | Alto | Confirmar con Carlos si el simulador los modela aparte antes de escribir el motor. |
| R-04 | El histórico ofrecido no es el histórico útil. Salesforce tiene lo cotizado; Core tiene lo operado. | Alto | Solicitar formalmente el par cotizado↔operado desde Core para la fase de recomendación. |
| R-05 | El histórico está sesgado por manipulación de variables. | Alto | Segmentar por perfil y antigüedad del socio; validar recomendaciones contra desempeño real antes de liberarlas. |
| R-06 | El criterio de Carlos no está codificado en el Excel. | Alto | Sesión dedicada de elicitación con Carlos, separada de la revisión de fórmulas. |
| R-07 | Identidad y permisos en WhatsApp sin diseño, siendo un requisito bloqueante. | Alto | Definir con Diego y Nelson el mapeo teléfono↔usuario y la política de excepciones antes de la fase de desarrollo. |
| R-08 | Iniciativas internas paralelas sin roadmap compartido: la capa, S3, IA en Nufi, agentización de Misha. | Alto | Pedir el roadmap y declarar explícitamente los puntos de acoplamiento. |
| R-09 | Ausencia total de línea base cuantitativa. | Alto | Pedir tres a cinco métricas medibles antes de arrancar. Es barato y cambia la conversación de precio a valor. |
| R-10 | Nufi como dependencia externa con cambios no anunciados. | Medio | Fuera de alcance de la POC. Registrar como riesgo de la solución integrada. |
| R-11 | Sergio Miranda, dueño del dolor de seguimiento, no ha participado. | Medio | Incluirlo en la siguiente sesión de descubrimiento. |
| R-12 | Diseño de solución entregado sin contrato, con riesgo de reutilización en un proceso de abasto. | Medio | Encuadre y autoría en todo material escrito que se entregue de aquí en adelante. |
Supuestos que sostienen el plan
- Que el Excel del cotizador es autocontenido y sus fórmulas son suficientes para reproducir el cálculo sin acceso al modelo de Salesforce.
- Que las seis variables acordadas producen un resultado suficientemente cercano al del simulador de 35 campos como para ser creíble frente al comité.
- Que la lista de variables que llegue por correo coincide con la acordada verbalmente en sesión.
- Que WhatsApp Business API estará disponible o que la POC puede demostrarse en un entorno equivalente sin bloquear la fecha.
- Que el acceso a Partner Community llega a tiempo para observar el proceso real, y no solo la demo de René.
- Que el comité que evalúa la POC comparte los criterios de Ash y Diego, y no introduce requisitos nuevos en la evaluación.
Próximos pasos
| # | Acción | Dueño | Cuándo |
|---|---|---|---|
| 01 | Enviar lista formal de variables del cotizador | Ash + René | Hecho · 18-ago |
| 02 | Entregar el simulador en Excel con fórmulas | Carlos / René | Hecho · 18-ago |
| 03 | Entregar el Excel de flujos de Nufi con documentos y validaciones cruzadas | René | Hecho · 18-ago |
| 04 | Extraer y compartir histórico de cotizaciones (≥3 meses) | Ash | Pendiente — único insumo abierto |
| 05 | Habilitar acceso a Salesforce Partner Community o sandbox | Ash | Sin fecha — fijarla |
| 06 | Verificar el simulador recibido: tabla de costo/renta por modelo de terminal, tratamiento de los tramos MSI, y catálogo de familias | DashOne | Primeras 24 h |
| 06b | Aclarar qué significa "venta directa" en los tramos de distribución de volumen | DashOne → Carlos | Esta semana |
| 07 | Recuperar y cerrar por escrito la lista numerada de preguntas del chat de la llamada | DashOne · Jules | Esta semana |
| 08 | Agendar sesión de elicitación dedicada con Carlos Córdoba sobre el criterio no codificado | DashOne + Ash | Esta semana |
| 09 | Solicitar formalmente el par cotizado↔operado desde Core | DashOne · Daria | Esta semana |
| 10 | Solicitar tres a cinco métricas de línea base | DashOne · Daria | Esta semana |
| 11 | Confirmar si sigue en pie la sesión de 30 min con Carlos, Manu y René | Ash | Esta semana |
| 12 | Construir y presentar la POC del cotizador en WhatsApp | DashOne | Fin de agosto · tolerancia 1ª semana de septiembre |
| 13 | Presentar resultado al comité interno y escalar a abasto | Ash | Posterior a la POC |
Con el alcance fijado por escrito y dos de los tres insumos críticos ya en mano, el camino crítico dejó de ser contractual y pasó a ser técnico. La prioridad ahora es la acción 06: verificar en las primeras horas que el simulador entregado cubra el costo por modelo de terminal y los tramos MSI. Si falta cualquiera de los dos, se escala el mismo día — son las dos piezas que pueden hacer que el motor calcule mal justo en los casos que más se negocian.
El histórico (acción 04) es el único insumo abierto y no bloquea la POC: el cálculo es determinístico y se valida con casos de referencia. Sí bloquea la fase de recomendación posterior.
Qué es la originación
Este apéndice existe porque el término se usó durante toda la sesión como vocabulario compartido, sin definirse nunca. Fijarlo por escrito evita que cada área lo interprete distinto en el PRD.
Originación es el proceso completo por el que un socio comercial convierte un comercio prospectado en una cuenta activa de NetPay — desde el primer contacto en campo hasta el alta operando en Core.
El ciclo de captación, cotización, expediente, contratación y alta de un comercio, ejecutado por un socio comercial sobre la estructura cliente → company → branch → store.
Todo lo que ocurre entre "encontré un comercio" y "el comercio ya está cobrando".
Descomposición del proceso
| Subproceso | Qué ocurre | Actor principal | Estado en el programa |
|---|---|---|---|
| Captación | Encuentro en campo. El socio no tiene RFC ni datos formales, solo interés. | Socio comercial | Hoy no existe en sistema Se resuelve en Excel o de memoria |
| Cotización asistida | Condiciones a partir de variables mínimas, con banda piso/techo y ruta de excepción a pricing. | Socio comercial · Pricing | Fase 1 · POC |
| Formalización | Alta de prospecto, validación de evidencia, apartado, y creación de la estructura company/branch/store. | Socio · equipo de evidencia | Rediseño posterior |
| Expediente | Solicitud y carga de documentos, KYB en Nufi, validación automática y humana. | Socio · Operaciones · Riesgo | Fase 2 |
| Contratación | Trámite de giro natural ante Prosa, generación de contrato, firma digital en Mifiel. | Altas | Sin cambio previsto |
| Alta y activación | Registro en Core, condiciones vigentes, habilitación para operar y cobrar. | Altas | Sin cambio previsto |
| Seguimiento | Estado del caso, siguiente paso, recordatorios. Hoy lo hace manualmente el equipo de Sergio Miranda. | Altas · socio | Transversal · fase 2 |
En el proceso actual, la formalización va antes que la cotización: hay que crear prospecto, esperar validación de evidencia, apartar y construir la estructura completa antes de poder simular una tasa.
El rediseño invierte ese orden. Hoy la originación exige capturar antes de saber si hay negocio; el rediseño la invierte — cotizar primero, capturar solo cuando hay interés.
Esa sola frase explica el proyecto entero sin mencionar inteligencia artificial, agentes ni WhatsApp. Es la lámina de apertura recomendada para el comité.
Nota de vocabulario
"Originación" es la palabra de NetPay, no una etiqueta impuesta. Aparece en su manual y en la forma en que Diego y René nombran los tipos de caso — originación tipo client, originación branch. Lo mismo aplica a apartado, company, branch, store, familia, giro y flow. Conservar su vocabulario íntegro es una decisión deliberada: reetiquetar el proceso de un cliente que lleva años con sus términos genera fricción sin aportar claridad.
Distinción a cuidar: NetPay usa onboarding para referirse al comercio final, no al proceso del socio. No son intercambiables.
El alcance real de lo que se ha hablado
La conversación con NetPay se ha sostenido bajo la etiqueta de "un bot de WhatsApp para atender asesores". Esa descripción nombra el canal y el usuario, pero no el trabajo. El alcance de lo que efectivamente se ha discutido, pedido y esperado es el rediseño del proceso de originación completo.
Esto no es una interpretación forzada: es lo que quedó registrado en la propia sesión. La tabla siguiente contrasta cada pieza tal como se enuncia coloquialmente contra lo que realmente implica.
| Cómo se enuncia | Qué es en realidad | Evidencia en sesión |
|---|---|---|
| "Un bot que cotiza" | Un motor de pricing con reglas de rentabilidad, mínimos por giro, banda piso/techo y ruta de excepción — desacoplado del CRM y editable por NetPay. | Misha pidió explícitamente un servicio de cotización separado, consultado por el agente. Ash pidió que fuera "robusto" y autogestionable. |
| "Que pida menos datos" | Inferencia sobre histórico y prellenado por comparables, con la carga de gobierno de datos que eso implica. | Diego: hay campos que en 98–99% toman el mismo valor. Misha: recomendar por similitud de perfil. |
| "Cotizar sin prospecto" | Inversión del orden del proceso. La formalización deja de ser prerrequisito y pasa a ser consecuencia del interés. | Ash pidió precotización sin generar prospecto. Es un cambio de proceso, no de interfaz. |
| "Que suba los documentos por ahí" | Integración al KYB vía API de Nufi, con ~30 flujos, validaciones cruzadas y flujo de rechazo. | Diego describió el depósito directo a Nufi sin exponer la URL al socio. |
| "Que le recuerde dónde va su caso" | Orquestación de estado a lo largo de cuatro sistemas, sustituyendo el seguimiento manual de un equipo. | Diego lo nombró como el segundo dolor. Hoy lo hace el equipo de Sergio Miranda a mano. |
| "Que ellos lo puedan actualizar" | Motor de reglas gobernable con versionado de políticas, productos, giros y tasas mínimas. | Pregunta de Manu, respaldada por Ash: autonomía total, sin dependencia del proveedor. |
| "Sacar el cotizador de Salesforce" | Capa de abstracción de originación. Un programa de arquitectura, no una funcionalidad. | Diego: "me urge sacarlo de ahí... vamos a hacer la capa". |
Por qué importa aclararlo
"Un bot de WhatsApp" tiene un precio de referencia en el mercado y un ancla mental asociada. El rediseño del proceso de originación de una adquirente no comparte ese orden de magnitud. Si el proyecto viaja a abasto bajo la etiqueta equivocada, se compara contra la categoría equivocada.
Nombrar el canal invita a evaluar el canal. Si el comité juzga la POC como "qué tan bien conversa el bot" en vez de "qué tan bien resuelve el proceso", se mide lo accesorio.
Bajo la etiqueta de bot, cada pieza nueva —documentos, seguimiento, permisos, autogestión— entra como "una cosita más del bot". Nombrado como proceso, cada pieza es una fase con su propio alcance y su propia contraprestación.
El proyecto grande que Diego ya declaró —la capa— no tiene proveedor asignado. Quien nombra el proceso enmarca la conversación. Es más fácil ser el socio de la originación que el proveedor del bot que después quiere crecer.
El alcance de la POC sigue siendo el acordado y confirmado por escrito: funcional, sin conexión, acotado a las variables del cotizador, en WhatsApp, para fin de agosto. Nombrar correctamente el programa no expande el entregable inmediato — lo encuadra. La POC es la primera pieza de un proceso, no un producto terminado que después se le agregan cosas.
Formulación recomendada
Arquitectura e infraestructura
Este tema no se abordó en la sesión del 18 de agosto pero está vivo en la conversación con el cliente desde llamadas anteriores. Se documenta aquí porque condiciona el diseño de la POC y porque la decisión debe quedar explícita antes de que el proyecto llegue al comité técnico de NetPay.
¿La solución se construye sobre el stack de Spin —AWS, Bedrock y los servicios que su equipo ya opera y audita— o sobre la infraestructura propia de DashOne?
Postura acordada: ejecución por fases
Entregar algo funcional y demostrable rápido, sin depender de accesos, aprobaciones de seguridad ni ciclos de provisioning del lado del cliente. Es lo que permite sostener la fecha de fin de agosto.
Una vez validada la solución y tomada la decisión de negocio, se migra a AWS/Bedrock dentro del entorno del cliente, con su gobierno de seguridad y arquitectura.
Prefiero sorprender a los end users que al equipo de ingeniería.
— Criterio rector de la secuencia
La frase resume el orden de prioridades. El valor de la POC se juega frente al socio comercial y frente al comité de negocio, no frente al área técnica — que evaluará la solución más adelante y con otros criterios. Optimizar primero para la aprobación de ingeniería consume el tiempo que la demostración necesita, y arriesga llegar a la fecha con una arquitectura impecable que nadie ha visto funcionar.
Hay que asegurar que el cliente no confunda las fases. Si NetPay entiende que la POC corre en infraestructura DashOne y no registra que la migración es parte del plan, quedan disponibles dos lecturas erróneas: que DashOne pretende retener la solución en su propio entorno, o que el compromiso con AWS/Bedrock —que el cliente ya dio por confirmado— se está diluyendo.
Cualquiera de las dos activa al área de seguridad en el peor momento: cuando el proyecto está buscando aprobación, no cuando está en ejecución.
Trade-off
| Dimensión | Infraestructura DashOne | Stack de Spin · AWS + Bedrock |
|---|---|---|
| Tiempo a demostración | Días Sin dependencias externas | Semanas Accesos, cuentas, revisión de seguridad, provisioning |
| Riesgo de cronograma | Bajo. El equipo controla todas las variables. | Alto. La fecha depende de terceros dentro del cliente. |
| Aceptación de seguridad | Pendiente. Requiere explicación y encuadre explícito. | Resuelta de origen Es el entorno que ya auditan. |
| Alineación con lo declarado por el cliente | Divergente si no se encuadra como fase. | Total. NetPay confirmó AWS/Bedrock como base por su "safe check de seguridad y arquitectura". |
| Acceso a datos productivos | Nulo — pero la POC no los requiere: el alcance acordado es sin conexión. | Viable. Necesario a partir de la fase de integración. |
| Costo de migración posterior | Existe. Se contiene diseñando desde el inicio con portabilidad. | Nulo — ya se nació ahí. |
| Autonomía del cliente | Baja mientras corra fuera. Contradice RNF-03 si se prolonga. | Alta. Es la condición para la autogestión que pidió Ash. |
| Percepción ante el comité | Riesgo de leerse como dependencia del proveedor. | Refuerza el mensaje de cero lock-in. |
Por qué la fase inicial fuera del cliente es defendible
- El alcance acordado la hace irrelevante. La POC es funcional sin conexión a Nufi ni Salesforce, y sin datos productivos. No hay dato sensible del cliente en juego, que es el motivo real por el que un área de seguridad exige su propio entorno.
- La fecha no admite el ciclo de provisioning. Fin de agosto responde a un comité interno de NetPay. Gastar esas semanas en habilitar accesos deja sin tiempo lo único que el comité va a evaluar.
- La decisión de AWS ya está tomada y no se está cuestionando. NetPay confirmó Bedrock como base y DashOne no ha propuesto lo contrario. Lo que está en discusión es únicamente dónde corre el prototipo, no dónde vivirá el producto.
Condiciones para que funcione
| # | Condición | Por qué |
|---|---|---|
| C-01 | Declarar la secuencia por escrito, en el mismo documento de alcance de la POC. | Es la mitigación directa de la advertencia de Daria. Sin registro escrito, la fase se lee como decisión permanente. |
| C-02 | Nombrar la fase inicial como entorno de demostración, no como "nuestra infraestructura". | Un entorno de demostración es transitorio por definición. Una infraestructura propia suena a destino. |
| C-03 | Diseñar desde el primer día con portabilidad: lógica desacoplada del proveedor de modelo, sin dependencias propietarias en el motor de cálculo. | Reduce el costo de la migración y hace creíble el compromiso de moverla. |
| C-04 | Presentar un plan de migración con esfuerzo estimado junto con la POC, no después. | Convierte la migración en un entregable planeado y no en una conversación pendiente que el cliente descubre solo. |
| C-05 | Anticipar la conversación con el área de seguridad antes de que la abran ellos. | Llegar con la respuesta lista cambia la dinámica frente a ser interpelado. |
| C-06 | Confirmar que el entorno de demostración no procesa dato real de comercios ni de socios. | Es el argumento que cierra la objeción. Debe ser cierto y verificable. |
Confusión de fases — el cliente entiende la infraestructura transitoria como definitiva. Alto Mitigado por C-01 y C-02.
Deuda de migración subestimada — lo construido rápido resulta caro de mover. Medio Mitigado por C-03 y C-04.
Objeción tardía de seguridad — el área técnica se entera en la presentación al comité. Alto Mitigado por C-05.
Percepción de lock-in — contradice el discurso de autonomía y autogestión que se sostuvo en sesión. Medio Mitigado por C-02, C-03 y C-04.
Formulación recomendada frente al cliente
La POC corre en un entorno de demostración de DashOne porque no procesa datos de NetPay y porque habilitar accesos consumiría el tiempo que necesita la demostración. El destino de la solución es AWS/Bedrock dentro del entorno de Spin, como se acordó, y el plan de migración se entrega junto con la POC. Lo que se está eligiendo es dónde corre el prototipo, no dónde vive el producto.